送信されたメッセージについてのアプリオリ情報を使用するデコーディングスキーム

专利摘要:
ワイヤレス通信送信のエンコードされたデータビットをデコードする方法および装置が提供される。エンコードされたデータビットの既知のビット値に対応する、１組のアプリオリビット値を発生させてもよい。アプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスは、考慮するための可能性あるデコーディングパスから除去される。除去されなかった可能性あるデコーディングパスのうちの残存デコーディングパスから、デコーディングパスを選択することにより、エンコードされたデータビットをデコードする。
公开号:JP2011509598A
申请号:JP2010541452
申请日:2008-07-17
公开日:2011-03-24
发明作者:キム、ジェ・ウォ；シム、ボク・テ；チャン、テ・リュン；パーク、ジュ・ウォン；パーク、ジョン・ヒョン；リー、チュン・ウォ
申请人:クゥアルコム・インコーポレイテッドＱｕａｌｃｏｍｍ Ｉｎｃｏｒｐｏｒａｔｅｄ；
IPC主号:H03M13-39

专利说明:

[0001] 〔発明の分野〕
本発明の実施形態は、一般的にワイヤレス通信に関連し、さらに詳細には、ワイヤレス送信をデコーディングすることに関連する。]
[0002] 〔関連技術の説明〕
ブロードバンドインターネット接続およびストリーミングメディアアプリケーションのような、ワイヤレス通信サービスの急速な成長が、より高いデータレートに対する要求を増加させることにつながっている。直交周波数分割多重（ＯＦＤＭ）および直交周波数分割多元接続（ＯＦＤＭＡ）のような多重化スキームの発展は、次世代のワイヤレス通信システムにとって重要である。これは、このようなスキームが、従来の単一搬送波変調スキームに対して、変調効率、スペクトル効率、柔軟性（例えば、差別化されたサービス品質を許容すること）、強いマルチパス耐性を含む多くの利点をもたらすことができるという事実に起因する。]
[0003] ＯＦＤＭおよびＯＦＤＭＡシステムは、エラー訂正を提供するために、送信機において、畳み込みエンコーダーを利用することが多い。畳み込みコードを使用して、ｍビットのデータストリングをｎビットに変換する。ここで、ｍ／ｎが、コーディングレートである。ビタビデコーダのようなデコーダが、受信した、エンコードされたｎビットをデコードして、元のｍビットのシーケンスを復元させるために、受信機において使用される。このスキームは、エンコードされたｎビットのうちの１つ以上を正しく受信しない場合であっても、元のｍビットのシーケンスを正しくデコードできることが多く、したがって、結果として、ビットエラーレートを減少させることになる。]
[0004] しかしながら、ワイヤレスサービスの信頼性および性能要求が絶えず増加しているので、引き続き、ビットエラーレートを継続的に減少させる必要性がある。]
[0005] １つの実施形態は、ワイヤレス通信送信のエンコードされたデータビットをデコードするための方法を提供する。方法は、一般的に、エンコードされたデータビットの既知のビット値に対応する、１組のアプリオリビット値を発生させることと、アプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスを、可能性あるデコーディングパスの集合から除去することと、除去されなかった可能性あるデコーディングパスのうちの残存デコーディングパスから、デコーディングパスを選択することにより、エンコードされたデータビットをデコードすることとを含む。]
[0006] １つの実施形態は、ワイヤレス通信送信のエンコードされたデータビットをデコードするデコーダを提供する。デコーダは、一般的に、エンコードされたデータビットの分岐メトリックを算出する分岐メトリックユニットと、分岐メトリックに基づいて、デコードされたビットを発生させる際に使用するデコーディングパスを選択する加算比較選択ユニットと、デコーディングパスを選択するとき、エンコードされたデータビットの仮定値に対応する１組の１つ以上のアプリオリビット値と一致しない、デコードされたビット値に対応する１つ以上のデコーディングパスを、加算比較選択ユニットによる考慮から除去するロジックとを具備する。]
[0007] １つの実施形態は、ワイヤレス通信のための受信機を提供する。受信機は、一般的に、ワイヤレス送信を受信して、１組のエンコードされたビットを発生させる受信機フロントエンドと、デコーダとを具備する。デコーダは、アプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスを、可能性あるデコーディングパスの集合から除去することと、除去されなかった可能性あるデコーディングパスのうちの残存デコーディングパスから、デコーディングパスを選択することとにより、エンコードされたビットをデコードするように構成されている。]
[0008] １つの実施形態は、ワイヤレス通信のための装置を提供する。装置は、一般的に、ワイヤレス送信を受信して、１組のエンコードされたビットを発生させる手段と、アプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスを、可能性あるデコーディングパスの集合から除去することと、除去されなかった可能性あるデコーディングパスのうちの残存デコーディングパスから、デコーディングパスを選択することとにより、エンコードされたビットをデコードする手段とを具備する。]
図面の簡単な説明

[0009] 上記で述べた本発明の特徴における方法を詳細に理解できるように、上記で簡潔に要約した本発明のさらに詳細な記述を、実施形態への参照により行う。実施形態のうちのいくつかを、添付の図面で示している。しかしながら、添付の図面は、本発明の典型的な実施形態のみを示しており、それゆえ、等しく有効な他の実施形態に対して本発明が認められるように、本発明の範囲を限定するものであると考えるべきではないことに留意すべきである。
図１は、本発明の実施形態にしたがった、例示的なシステムを図示している。
図２は、本発明の実施形態にしたがった、アプリオリデコーディングが可能な受信機のブロック図である。
図３は、本発明の実施形態にしたがった、アプリオリデコーダのブロック図である。
図４は、本発明の実施形態にしたがった、アプリオリ情報（ＡＰＩ）ビットの例を図示しているアプリオリデコーダのブロック図である。
図５は、本発明の実施形態にしたがった、トレリス図の状態遷移の例を図示している。
図６は、本発明の実施形態にしたがった、アプリオリデコーディングのための例示的な動作のフローチャートである。
図７は、アプリオリ情報ビットの例示的な値を用いた、図５のデコーダを図示している。
図８は、全組のデコーディングパスと、本発明の実施形態にしたがった、アプリオリ情報ビットに基づいて減少されている１組のデコーディングパスとを用いた、トレリス図の例を図示している。
図９は、本発明の実施形態にしたがった、第１の組のアプリオリ情報を考慮したデコーディングの例示的な結果を示している。
図１０は、本発明の実施形態にしたがった、第１の組のアプリオリ情報を考慮したデコーディングの例示的な結果を示している。
図１１は、本発明の実施形態にしたがった、アプリオリデコーダおよび仮定エンジンを持つ受信機のブロック図である。
図１２は、本発明の実施形態にしたがった、仮定エンジンのブロック図である。
図１３は、アプリオリ情報ビットに基づいて、デコーディング仮定を発生させるために使用される、例示的なメッセージフォーマットを示している。
図１４Ａは、アプリオリ情報ビットに基づいた、異なるデコーディング仮定を示している。
図１４Ｂは、アプリオリ情報ビットに基づいた、異なるデコーディング仮定を示している。
図１４Ｃは、アプリオリ情報ビットに基づいた、異なるデコーディング仮定を示している。
図１４Ｄは、アプリオリ情報ビットに基づいた、異なるデコーディング仮定を示している。
図１４Ｅは、アプリオリ情報ビットに基づいた、異なるデコーディング仮定を示している。
図１４Ｆは、アプリオリ情報ビットに基づいた、異なるデコーディング仮定を示している。
図１４Ｇは、アプリオリ情報ビットに基づいた、異なるデコーディング仮定を示している。
図１５は、本発明の実施形態にしたがった、異なるＡＰＩ仮定に対するデコーディングの例示的な結果を示している。
図１６は、本発明の実施形態にしたがった、異なるＡＰＩ仮定に対するデコーディングの例示的な結果を示している。
図１７は、本発明の実施形態にしたがった、異なるＡＰＩ仮定に対するデコーディングの例示的な結果を示している。] 図１ 図１０ 図１１ 図１２ 図１３ 図１４Ａ 図１４Ｂ 図１４Ｃ 図１４Ｄ 図１４Ｅ
詳細な説明

[0010] 本発明は、一般的に、送信に関するアプリオリ情報を使用して、畳み込みエンコードされたワイヤレス送信をデコードするための技術および装置を提供する。アプリオリ情報と一致しないビットを含む、可能性あるデコードされたビットストリームを除外することにより、可能性あるデコードされたビットストリームの集団を効率的に減少させるために、アプリオリ情報を使用してもよい。誤ったデータを導くこれらの「既知の間違った」パスを除去することにより、いくつかの状況において、デコードされるビットのエラーレートを改善することができる。]
[0011] ここで使用するように、用語、アプリオリ情報は、一般的に、既知のまたは仮定の原因から、必然的に関連する結果へと処理するための情報のような、事前に知られている情報に関連している。下記でより詳細に記述するように、送信に関連するアプリオリ情報の例は、あるメッセージ中の既知の情報ビットを含んでいる。このような既知の情報ビットの例は、標準規格により指定されるような値を持つ予約ビットを、あるいは、既知の値を有するまたは以前の送信中の値に基づいて予測可能な値を有するビットとを含んでいる。ＡＰＩ値とは異なる値に対応するパスを除外することによってデコーディング性能を向上させるために、これらの既知のビットポジションおよび（ここで「ＡＰＩ値」と呼ばれる）ビット値をデコーディングプロセス中で使用してもよい。]
[0012] 〔例示的な環境〕
図１は、基地局１１０から移動局１２０へのワイヤレス信号を処理するために本発明の実施形態を利用する、例示的なシステムを図示している。基地局１１０は、セルラ電話機タワーのような、固定ロケーションに設置されているワイヤレス通信局であってもよい。移動局１２０は、セルラハンドセットまたは他のタイプの移動体デバイスのような、基地局１１０と通信することが可能な何らかの適切なタイプのユーザ機器（ＵＥ）であってもよい。] 図１
[0013] 基地局１１０と移動局１２０は、１つ以上のアンテナ１１２、１２２をそれぞれ使用して、ならびに、直交周波数分割多重（ＯＦＤＭ）および直交周波数分割多元接続（ＯＦＤＭＡ）のような変調スキームを用いる何らかの適切なワイヤレス通信技術を使用して、通信してもよい。いくつかの実施形態に対して、基地局と移動局との間の通信は、部分的にまたは完全に、ＩＥＥＥ８０２．１６（ワールドワイドインターオペラビリティフォーマイクロウェーブアクセス、ＷｉＭＡＸ）および８０２．２０（モバイルブロードバンドワイヤレスアクセス、ＭＢＷＡ）の標準規格のファミリーのような、さまざまな米国電気電子学会（ＩＥＥＥ）標準規格に準拠していてもよい。]
[0014] いくつかの適用では、基地局１１０が、一般的にフォワードリンクと呼ばれるものを介して、移動局にデータを送信する一方で、移動局１２０が、リバースリンクを介して、基地局１２０にデータを送信する。下記でより詳細に記述するように、異なるタイプのアプリオリ情報が、フォワードおよびリバースリンク送信に対して利用可能であってもよい。このアプリオリ情報は、基地局１１０と移動局１２０との間での、あるメッセージのタイミングおよびコンテンツに関する情報を含んでいてもよく、結果として、送信における１つ以上のビットの値が知られることになる。]
[0015] ここで記述する技術を、基地局１１０、移動局１２０、または、その両方において行われるデコーディングに利用してもよい。下記でより詳細に記述するように、送信内での特定のビットロケーションの値を決定するために、基地局１１０と移動局１２０との間で送信される、異なるタイプのメッセージについてのアプリオリ情報を使用してもよい。]
[0016] 図２は、送信された信号を受信することが可能な受信機の、１つの実施形態に対する例示的なコンポーネントのブロック図を図示している。１つ以上のアンテナ２０２が、送信機からの送信信号を受信して、信号を無線周波数（ＲＦ）フロントエンド２１０に送る。ＲＦフロントエンド２１０は、送信信号を受け取って、自動利得制御（ＡＧＣ）、高速フーリエ変換（ＦＦＴ）ブロック、チャネル推定器、ならびに、搬送波対干渉およびノイズ比（ＣＩＮＲ）推定器のような、デジタル信号処理用にこの信号を準備する何らかの適切な回路を備えていてもよい。] 図２
[0017] その後、ＲＦフロントエンド２１０からの信号を信号処理ブロック２２０に送る。信号処理ブロック２２０は、副搬送波の割り当て解除、信号のデマッピング、および、これらに類するもののための何らかの適切な回路を備えていてもよい。信号処理ブロック２２０の出力は、１組のエンコードされたビットである。エンコードされたビットはチャネルデコーダ２３０に転送され、チャネルデコーダ２３０は、対応する送信についてのアプリオリ情報を使用して、エンコードされたビットをデコードする。]
[0018] 〔アプリオリデコーディング〕
図３は、本発明の実施形態にしたがった、アプリオリ情報に基づいてデコーダ動作を行うことが可能な、デコーダ２３０のブロック図である。図示する例は、ビタビデコーディングスキームを例として示しているが、ここで提示するアプリオリデコーディング技術は、ターボコーディング／デコーディング、低密度パリティー検査（ＬＤＰＣ）コーディング／デコーディング、ＲＳコーディング／デコーディング、ＢＣＨコーディング／デコーディング、および、他のさまざまなスキームのような、他のタイプのデコーディングスキームにも適用することができる。] 図３
[0019] 組織コードを利用するスキームのケースでは、コード化ビットは、組織ビット（エンコーディング前の情報）とパリティービット（エンコーディングに起因する冗長ビット）とを含んでいてもよい。ＡＰＩデコーディングスキームを組織ビットに適用してもよい。いいかえると、ＡＰＩビット値は、使用される特定の組織コードに基づく、組織ビットの既知の値を含んでいてもよい。組織コードを利用するシステムにＡＰＩを適用するために、デコーダのフロントエンドにおいて、受信したデータのビットを（既知の／予測される）ＡＰＩビット値に置換してもよい。このように、組織デコーダに対してＡＰＩを使用して、デコーディングが成功する確率を増加させることができる。]
[0020] デコーダ２３０は、分岐メトリックユニット２３２と、加算比較選択（ＡＣＳ）ロジック２３４と、トレースバック（ＴＢ）ユニット２３６とを備えており、１組の「ソフト（またはハード）」受信／エンコードされたビット２４０から、１組のデコードされたビット２４６を発生させる。分岐メトリックユニットは、一般的に、分岐メトリックを算出するように機能する。分岐メトリックは、受信したシンボル（ビットの組）とコードアルファベット中のシンボルとの間の正規化された距離を表している。ＡＣＳユニット２３４は、一般的に、分岐メトリックデータをコンパイルして、デコーディングパス（Ｋの拘束長を仮定すると、２Ｋ−１個のパス）に対するメトリックを発生させ、これらのデコーディングパスのうちの１つを最適なものとして選択する。これらの選択の結果が、トレースバックユニット２３６のメモリに書き込まれる。トレースバックユニット２３６は、記憶した判定からパスを回復する。その後、回復したパスの遷移に基づいて、１組のデコードされたビットを発生させることができる。]
[0021] アプリオリ情報と一致しないビット値に対応するデコーディングパスの選択を防ぐために、１組のＡＰＩビット２５０により、デコーダコンポーネントのうちの１つ以上を制御してもよい。いいかえると、ＡＰＩビット２５０は、デコードされているビットのシーケンス中のあるビットロケーションに対して知られている特定の値（「０」または「１」）を示すために十分な情報を含んでいる。ＡＰＩビット２５０において指定される値以外の値を有する任意のビットストリングは、有効なデコードビットストリングではない。したがって、デコーダは、これらの無効なビットストリングに対応するデコーディングパスを、パス選択中に考慮から除去することができる。]
[0022] 図４で図示しているように、いくつかの実施形態に対して、無効なデコードビットストリングに対応するデコーディングパスを除外するために、ＡＣＳユニット２３４は、ＡＰＩビット２５０により制御されてもよい。ＡＣＳ動作中に、ＡＰＩビット２５０を使用して、ＡＰＩ値と一致しないエンコードビット値に対応する、特定のデコーディングパス遷移を減少させてもよい。] 図４
[0023] ＡＰＩビット２５０は、一般的に、アプリオリ情報に基づく、既知の（または予測可能な）ビット値を有する、デコードビットストリング中の１つ以上のビットを識別するために十分な情報と、付加的に、これらのビット値がいくつであるかということとを含んでいる。この情報を伝達する実際のフォーマットは、異なる実施形態ごとに、および、実際のインプリメンテーションスキームにしたがって、変化してもよい。]
[0024] 例えば、いくつかの実施形態に対して、ＡＰＩビット２５０は、３つのタイプの情報を含んでいてもよい。これは、ビットポジション２５２の表示、ビット値２５４、および、オプション的に、ＡＰＩマスクビット２５６である。ビットポジション２５２は、既知の値を有する、（エンコードされたシーケンス内での）ビットロケーションの表示を提供する。一方で、ビット値２５４は、エンコードされたビットの実際の既知の値（「０」または「１」）を提供する。下記で詳細に記述するが、図７は、このフォーマットにしたがった、ビットポジションと、ビット値と、マスクビットとに対する例示的な値を図に提供している。] 図７
[0025] ＡＰＩビットポジション２５２は、トレリス構造中の、既知の／予測されるエンコードビットのポジションに対応するビットポジションを識別することができる。１つの実施形態にしたがうと、ＡＰＩビットポジション２５２が、既知の値を有するビットポジションを明示的に識別することができる一方で、他のすべてのビットポジションは、“未知”であると考えられる。したがって、ビット値２５４中の「０」または「１」の対応するビット値を使用して、トレリス構造中の有効な遷移を識別し、無効な遷移を含むデコーディングパスを効率的に除去してもよい。]
[0026] 例えば、図５は、３ビット状態を有するトレリス構造の状態遷移の例を図示している。図示している例は、１／２のコーディングレートと、Ｋ＝４（３ビット、Ｋ−１、状態レジスタ）とを仮定している。実線の矢印は「０」入力ビットに対応する状態遷移を示している一方で、破線の矢印は「１」入力ビットに対応する状態遷移を示している。ＡＰＩデコーディングにしたがうと、既知の値と一致しない入力ビットに対応する状態遷移を、考慮から除外することができる。それにより、これらの遷移を含む任意のパスを、最終的な選択から効率的に除外することができる。] 図５
[0027] 例として、この状態に対する既知のＡＰＩビット値が「０」である場合、実線での状態遷移が評価されるだろう。一方で、破線での状態遷移は、選択に対して考慮すべきでない無効なパスの一部であるので、算出する必要がない。上記で記述したように、状態メトリックの値をワーストケース値にセットすることにより、次の遷移において、これらの遷移を効率的に除外することができる。無効なパスを選択から除外することによりビットエラーレートを減少させることに加えて、ＡＰＩビット値に基づいて遷移の数を無くすことによって、ＡＣＳユニット中での計算の数も減少させることができる。]
[0028] いくつかの実施形態に対して、そのＡＰＩビット値を無視すべきであるビットポジションを識別するために、ＡＰＩマスクビット２５６を利用することにより、マスク機能を実現してもよい。このようなマスク機能は、例えば、標準規格が変わることにより、以前に既知だったビット値が未知になるときに、有用であり、柔軟性を追加できる。マスクビットをセットすることにより、このような変化に効率的に適応するシンプルなメカニズムを提供できる。もはや既知の値を持っていないビットポジションの識別を除去するために、ＡＰＩビットポジション２５２を操作することによっても、マスク機能を実現することができる。これにより、ビットマスク値中の値を変化させること、および／または、ビットマスク値に対する必要性をまったく無くすことに対する代替手法を提供することができる。]
[0029] 図６は、ＡＰＩデコーディングのための例示的な動作６００を示している。アプリオリ情報に基づいて仮定を発生させることにより、６０２において動作を開始する。６０４において、仮定のＡＰＩビット値と一致しないビット値に結果としてなるデコーディングパスが除去される。最後に、６０６において、残存パスのうちの１つを選択することに基づいて、デコーディングが行われる。] 図６
[0030] ここで使用するように、用語、仮定は、例えば、既知の値を持つビットポジションを示し、かつ、これらのビットに対する値を指定する、特定の組のＡＰＩビットに一般的に関連している。下記でより詳細に記述するように、いくつかの実施形態に対して、例えば、ＭＡＣプロセッサからのメッセージ情報に基づいて、１つ以上の仮定を発生させる（ここで「仮定エンジン」と呼ばれる）別のロジックを提供してもよい。]
[0031] 図７は、ＡＰＩデコーダに適用される６ビットストリームに対する仮定の１つの例を図示している。図示している仮定は、ＡＰＩビットポジション値［１２３５］を通して、デコーディングに使用するためのビットポジション１、２、３、および５に、ＡＰＩビット値が存在していることを示している。図示しているスキームにしたがうと、対応するＡＰＩビット値［１０１１］は、これらのポジションにおけるビットに対するビット値が、ビット１＝１、ビット２＝０、ビット３＝１、および、ビット５＝１であることを示している。いくつかの実施形態に対して、マスク機能がビットのいずれにも適用されないことを示すために、［００００］のＡＰＩマスクビット値を使用してもよい。一方で、ＡＰＩデコーディングからビットを除外するために、マスクビットを例えば［０００１］にセットして、ビットポジション５をマスクすることができ、結果として［１０１Ｘ］の実効ビット値になる。] 図７
[0032] 当然、ＡＰＩビットポジション値を制御することにより、同様にマスク機能性を実現してもよい。例として、ビットポジション値から５を除去することによっても、ビットポジション５を効率的にマスクアウトすることができ、結果として、［１２３］のビットポジション値になり、対応するＡＰＩビット値は［１０１］となる。このスキームでは、別のマスク値データ構造に対する必要性なく、ＡＰＩビットポジションを効率的にマスクすることができる。]
[0033] 代替的なスキームでは、ＡＰＩビット値および対応するＡＰＩマスク値のみを使用してもよい。例として、例えば、デフォルトにより、または、ＡＰＩポジション値中のすべてのビットポジションの明確な表示（例えば、［１２３４５６］）により、ビットシーケンス中のすべてのポジションがＡＰＩデコーディングのために使用されることを仮定してもよい。いずれのケースにおいても、ＡＰＩマスク値を使用して、対応するＡＰＩビット値を何ら持たないビットポジションを識別することができる。例えば、ビットポジション４および６に対応するＡＰＩビット値を無視すべきであることを示す「１」値を用いて、［０００１０１］のＡＰＩマスク値を使用してもよく、結果として、［１０１Ｘ１Ｘ］の対応するＡＰＩビット値になる。]
[0034] 図８は、デコーディング中に、考慮されるデコーディングパスの数を減少させるために、図７で示した仮定のＡＰＩビット値がどのように適用されるかを図示している。上図８１０は、すべての入力ビットが未知であると仮定する、従来のデコーディングスキームにおいて考慮されるすべての可能性あるパスを図を通して示している。しかしながら、下図８２０により図示しているように、ＡＰＩデコーディングスキームは、既知のＡＰＩビット値を使用することに基づいて、多数のパス遷移を除外して、大幅に減少した数のパスをサーチする。] 図７ 図８
[0035] 図８２０を左から右に横断することにより、ＡＰＩビット値に基づくパスの減少を説明する。対応する遷移に対する既知のＡＰＩ値が、上部にわたって列挙されている。第１の遷移に対して、ビット値は既知「１」であり、結果として、０入力ビットに対応する実線パスの遷移が除去される。このことにより、結果として、状態ノード１００ｂ、１０１ｂ、１１０ｂ、および、１１１ｂへの遷移になる。]
[0036] 第２の遷移は、「０」の既知ビット値に対応しており、結果として、破線パスの遷移が除去される。このことにより、結果として、状態ノード０１０ｂおよび０１１ｂへの遷移になる。第３の遷移は、「１」の既知ビット値に対応しており、結果として、実線パスの遷移が除去される。このことにより、結果として、単一の状態ノード１０１ｂへの遷移になる。]
[0037] しかしながら、第４の遷移に対するビット値は未知である。それゆえ、両方の可能性ある遷移パスが評価される。このことにより、結果として、状態ノード０１０ｂおよび１１０ｂへの遷移になる。第５の遷移は、「１」の既知ビット値に対応しており、結果として、実線パスの遷移が除去される。このことにより、結果として、状態ノード１０１ｂおよび１１１ｂへの遷移になる。第６の遷移に対するビット値は、再度未知である。それゆえ、両方の可能性ある遷移パスが評価され、結果として、状態ノード１０１ｂから状態ノード０１０ｂおよび１１０ｂへの遷移と、状態ノード１１１ｂから状態ノード０１１ｂおよび１１１ｂへの遷移になる。]
[0038] これらの残存パスに対する分岐メトリックを評価して、最適なパスを選択し、対応する組のデコードされたビットを発生させることができる。無効なビットシーケンスに対応するデコーディングパスを除外することにより、ＡＰＩデコーディングを使用して、ビット／パケットエラーレートを改善できる。さらにノイズが多い環境では、より大幅な改善が期待される。]
[0039] 図９は、ＩＥＥＥ８０２．１６ｅ標準規格のフレーム制御ヘッダー（ＦＣＨ）／ダウンリンクフレームプリフィックス（ＤＬＦＰ）メッセージのデコーディングをシミュレートしたものに関する、信号対ノイズ比（ＳＮＲ）に対するパケットエラーレート（ＰＥＲ）の例示的なグラフである。このタイプのメッセージは、２４ビットの情報を含んでいる。これらのうち、５ビットが、標準規格にしたがってゼロにセットされる予約ビットである。シミュレートされた例では、「０」の既知のビット値が２４ビットストリング中の対応するロケーションにあるというアプリオリ情報として、これらの５予約ビットが使用される。このシミュレーションは、変調とコーディングを、ＱＰＳＫ、ＴＢＣＣ（ｒ＝１／２）、４の反復ファクターおよび２の重複ファクターと仮定し、受信側（ＲＸ）における反復最大比合成（ＭＲＣ）も仮定する。] 図９
[0040] 示しているように、ＡＰＩデコーディングスキームは、加法性ホワイトガウスノイズ（ＡＷＧＮ）環境において、従来のデコーディングスキームと比べて性能が改善されていることを示す。例えば、（ＡＰＩを考慮することなく）従来のデコーディングと比較したときに、ＡＰＩデコーディングスキームは、ＡＷＧＮチャネル中のＰＥＲ１０−２において、約０．６ｄＢ利得を示している。]
[0041] 図１０は、図９と類似した図だが、対応するシミュレーションは、反復最大比合成（ＭＲＣ）と受信側（ＲＸ）における重複との両方を仮定する。示しているように、この例では、ＡＰＩデコーディングスキームなしのデコーディングと比較すると、ＡＰＩデコーディングスキームは、ＡＷＧＮチャネル中のＰＥＲ１０−２において、おおよそ０．７５ｄＢ利得を示している。] 図１０ 図９
[0042] 〔仮定エンジン〕
上記で記述したように、いくつかの実施形態に対して、仮定エンジンを提供して、「仮定」を発生させてもよい。それぞれの仮定は、ＡＰＩデコーディングを行う際に使用するための１組のＡＰＩビット値を含んでいる。特定のインプリメンテーションにしたがって、仮定エンジンは、単一の仮定、または、複数の仮定を発生させてもよい。複数の仮定は、どのビットが既知の値を有し、それらのビットの既知の値がいくつであるかという点で異なっていてもよい。複数の仮定を評価することは、例えば、所定のシーケンスに対して、限られた数の有効なビットの組み合わせしかないときには有用である。]
[0043] 図１１は、ＡＰＩデコーダ２３０と仮定エンジン１１１０を具備する、受信機回路１１００を図示している。図示しているように、仮定エンジン１１１０は、メッセージに関する情報を媒体アクセス制御（ＭＡＣ）プロセッサ１１２０から受け取ってもよく、ＡＰＩデコーダ２３０による使用のためにＡＰＩビット値（仮定）を発生させる。ＡＰＩデコーダ２３０は、仮定エンジン１１１０により提供されたＡＰＩビット値を使用して、受信したソフト（またはハード）ビットＲｓをデコードし始める。ＡＰＩデコーダ２３０は、デコードされたデータビットＲｄを出力する。デコードされたデータビットＲｄはメッセージパーサー１１３０に配信される。] 図１１
[0044] デコードされたビットが一種のメッセージに対するものであると、メッセージパーサー１１３０が検出した場合、メッセージがパーズされて、ＭＡＣ（媒体アクセス制御）プロセッサ１１２０に配信される。ＭＡＣプロセッサ１１２０は、あるタイプのプロトコル解析器として機能してもよく、受信したデータを解析して、例えば、次の可能性あるメッセージタイプが何であるか、および、どのようなタイミングになるだろうかを決定しようとする。]
[0045] 例として、ＭＡＣプロセッサ１１２０は、第１の到来メッセージ（またはデータ）がＦＣＨ／ＤＬＦＰメッセージであろうと認識することができる。ＦＣＨ／ＤＬＦＰメッセージの後に、ダウンリンクプリアンブルが続く。いくつかのケースでは、ＭＡＣプロセッサ１１２０は、以前のフレームからの何らかの情報を使用して、例えば、コーディングレート、メッセージ長、または、他の何らかのパラメータを決定してもよい。ＭＡＣプロセッサ１１２０は、この情報を仮定エンジン１１１０に提供してもよい。仮定エンジンは、この情報を使用して、特定のビットロケーションに対する既知のビット値を抽出して（またはビット値を予測して）、ＡＰＩ情報を発生させ、ＡＰＩデコーダに転送するだろう。]
[0046] 図１２は、ＭＡＣプロセッサにより提供されたアプリオリ情報とメッセージ情報とに基づいて、デコーディング仮定を発生させるために使用される、例示的な仮定エンジン１１１０を図示している。図示しているように、仮定エンジンは、メッセージタイプの表示を受け取り、ロジック１２１０に入れて、メッセージタイプにより指定される対応するメッセージを導出し、フォーマットロジック１２２０によりメッセージのフォーマットを解析する。] 図１２
[0047] いくつかの実施形態に対して、（標準規格にしたがって既知の値にセットされる予約ビットのような）固定の／既知のビット値を持つビットロケーションに加えて、予測可能である情報を用いて、仮定を発生させてもよい。例として、ビット情報は、以前に受信したメッセージからの値に基づいて、予測可能であるかもしれない（例えば、１つのメッセージから次のメッセージまでに、コーディングタイプが変化する可能性は低いと思われる）。]
[0048] したがって、分類ロジック１２３０は、所定のメッセージ中のビット情報を少なくとも３つのカテゴリー、固定情報、予測可能情報、および、可変情報に分類できる。固定（既知の）情報は、初期ステージから１００％わかるように固定されている情報に、または、何らかの条件下において（例えば、関連するメッセージのデコーディング結果をチェックした後に）わかるいくつかのビット値に、一般的に関連している。例えば、デコードされるデータよりも前に配置されることがわかっているメッセージまたはデータのような、デコードされるデータに関連するメッセージのデコード結果を解析してもよく、解析したデータからＡＰＩ情報を抽出してもよい。]
[0049] 予測可能情報は、ある条件または仮定の下で予測可能である情報を含んでいてもよく、そのため、１組の１つ以上のビットに対して、異なる候補値またはビットの組み合わせを提供することができる。異なる候補値は、異なる仮定に含まれていてもよい。例えば、予測可能情報は、ある条件または仮定の下で予測可能な何らかの情報を、あるいは、関連するメッセージのデコーディング結果をチェックした後に予測可能である情報を含んでいてもよい。]
[0050] 可変情報は、一般的に、未知のまたは予測することが非常に難しい情報を含んでおり、そのため、一般的に、ＡＰＩビット値として使用されない（例えば、これらのビットロケーションに対するＡＰＩビットポジション値は、「０」にセットされる）。情報ビットを分類した後に、仮定エンジンの仮定ＡＰＩおよび配信ロジック１２４０が、分類した情報を使用して、１組または複数組の（各組が仮定に対応する）ＡＰＩビット値を発生させることができる。例えば、ロジック１２４０は、デコーダ２３０に出力する、ＡＰＩビットロケーション、ビット値、および、マスクストリングを構築してもよい。]
[0051] ここで提示するＡＰＩデコーディングスキームは、さまざまな異なるタイプのメッセージに適用することができる。例えば、ＡＰＩデコーディングは、下記で記述するような、フレーム制御ヘッダー（ＦＣＨ）ダウンリンクフレームプリフィックス（ＤＬＦＰ）メッセージ、通常のＤＬＭＡＰメッセージ、圧縮されたＤＬ ＭＡＰメッセージ、ＵＬ ＭＡＰメッセージ、帯域幅要求（ＢＷ−ＲＥＱ）メッセージ、初期レンジング要求（ＩＲＮＧ−ＲＥＱ）メッセージ等に適用してもよい。]
[0052] 図１３で表しているように、フレーム制御ヘッダー（ＦＣＨ）ダウンリンクフレームプリフィックス（ＤＬＦＰ）メッセージ１３００は、固定、予測可能、および、可変として分類できる、さまざまなビットの情報の好例を提供する。ＦＣＨメッセージのフォーマットおよびコンテンツは、ＩＥＥＥ８０２．１６ｅ ＯＦＤＭＡ標準規格中で規定されている。ＤＬＦＰは、ＦＣＨチャネルのコンテンツである。ＤＬＦＰは、各フレームの初めに送信されるデータ構造であり、現在のフレームに関する情報を含んでおり、ＦＣＨに対してマッピングされる。それゆえ、フレーム全体を処理するためには、ＤＬＦＰのデコーディングの成功が非常に重要となる。いくつかのビットの分類は、時間にわたって、例えば、初期の獲得状態から第１のメッセージフレームの検出までの遷移の後に、変化するかもしれない。] 図１３
[0053] 例として、ビットマップフィールド１３１０は６ビットを含んでおり、各ビットは、対応するメッセージグループがセグメントにより使用されているか否かを示している。初期の獲得状態では、これらのビットは未知である。しかしながら、初期のデコーディングおよびメッセージセグメントの識別の後に、ビットのうちの少なくとも１つが識別されるだろう（例えば、第１のメッセージグループビットは、ＡＰＩビット＝「１ＸＸＸＸＸ」として使用されると仮定する）。さらに、通常の動作状態では、基地局が、以前のフレーム中と同じビットマップを送ると仮定されるので、移動局は、ビットのうちの６つすべてを予測できる。]
[0054] 前に記述したように、予約フィールド１３２０および１３２２のビットは、標準規格が変化しない限り、依然として固定のままだろう。対照的に、反復タイプフィールド１３３０の２ビットは、予測するのが難しく、フレームごとに変化するかもしれない。]
[0055] ３ビットのコーディングタイプフィールド１３４０は、異なる方法で分類して、多数の異なる仮定を発生させるために使用してもよい。例えば、コーディングのタイプに何も条件をつけなければ、３ビットフィールドを可変として扱うことができる。しかしながら、アプリオリ情報を使用して、これらのビットのうちのいくつかを固定として扱ってもよい。例えば、ＷｉＭＡＸの現在のバージョンが、ＴＢＣＣ（０ｂ０００）およびＣＴＣ（０ｂ０１０）の２つのタイプのコーディングのみをサポートすることがわかっている場合、第１および第３のビットを「０」の既知のビット値（ＡＰＩビット＝「０ｂ０Ｘ０」）として扱ってもよい。]
[0056] ８ビットの長さフィールド１３５０はフレームごとに変化するかもしれないが、ビットのうちのいくつかを異なる方法で分類してもよい。例として、長さフィールドに何も制限を課さなければ、８ビットはすべて可変になるだろう。しかしながら、たいていのケースでは、ＤＬ−ＭＡＰの長さは２＾７より小さくなるので、ＭＳＢは「０」（ＡＰＩビット＝「０ｂ０ＸＸＸＸＸＸＸ」）であると予測できる。この予測は真でないかもしれないが、達成されるビットエラーレートの改善は、異なる仮定を使用して再デコードしなければならない際の何らかの性能的不利よりも価値がある。例えば、長さが、２＾６より小さい（ＡＰＩビット＝「０ｂ００ＸＸＸＸＸＸ」）、または、２＾４より小さい（ＡＰＩビット＝「０ｂ００００ＸＸＸＸ」）と仮定すると、類似の方法において、よりアグレッシブな仮定を発生させることができる。]
[0057] 図１４Ａ〜１４Ｇは、上記で記述した情報と、可能性ある分類と、仮定とに基づく、ＦＣＨ／ＤＬＦＰメッセージに対する複数のＡＰＩデコーディングの仮定例を示している。仮定は異なるレベル（Ｌ０〜Ｌ６）を有するものとして参照され、異なるレベル（Ｌ０〜Ｌ６）は、既知のビット値を有するものとして扱われるビットの数に基づいて、仮定がいかに「アグレッシブ」であるかを一般的に表現している。] 図１４Ａ 図１４Ｂ 図１４Ｃ 図１４Ｄ 図１４Ｅ 図１４Ｆ 図１４Ｇ
[0058] まずはじめに図１４Ａを参照すると、各フレーム中の第１のメッセージのケースにおけるように、Ｌ０仮定は、ＡＰＩビット値がない（仮定がない）ケースに対応している。いいかえると、メッセージがデコードされていないので、ＡＰＩ値を発生させるために使用できるメッセージ情報がない。図１４Ｂは、第１のレベル（Ｌ１）仮定を示しており、予約ビット値のみが仮定中で使用されている。] 図１４Ａ 図１４Ｂ
[0059] 図１４Ｃは、Ｌ２仮定を示している。Ｌ２仮定は、予約ビット値に加えて、仮定中で使用されるビットマップビット値（第１のフレーム中で示されるメッセージグループ）を含んでいる。図１４Ｄは、Ｌ３仮定を示している。Ｌ３仮定は、Ｌ２仮定に比べて、以前のフレームで使用された残存ビットマップビット値を追加している。] 図１４Ｃ 図１４Ｄ
[0060] 図１４Ｅは、Ｌ４仮定を示している。Ｌ４仮定は、Ｌ３仮定に比べて、サポートされているコーティングタイプＴＢＣＣおよびＣＴＣに共通するコーディングフィールドビット値を追加している。図１４Ｆは、Ｌ５仮定を示している。Ｌ５仮定は、長さが２＾６より小さいという仮定に基づいて、Ｌ４仮定に比べて、長さフィールドの上位２つのビットを追加している。図１４Ｇは、Ｌ６仮定を示している。Ｌ６仮定は、長さが２＾４より小さいという仮定に基づいて、Ｌ５仮定に比べて、長さフィールドのさらに２つのビットを追加している。] 図１４Ｅ 図１４Ｆ 図１４Ｇ
[0061] 上記で記述した方法において、誤ったデータに対応する多数のデコーディングパスを減少させるために、これらの仮定のそれぞれに対するビット値が、ＡＰＩデコーダにより使用されてもよい。当然、図１４Ｂ〜１４Ｇで示した仮定は、例示的なものに過ぎない。さらに、示した仮定は、段々とアグレッシブになって、より多くの既知のビット値を含むようになっているが、当業者は、これらの例で示したビット値の異なる組み合わせを使用して、他の仮定を発生させることができることを認識するだろう。] 図１４Ｂ 図１４Ｃ 図１４Ｄ 図１４Ｅ 図１４Ｆ 図１４Ｇ
[0062] 上記で記述したように、誤ったデータに対応するデコーディングパスを除去するために、これらの異なる仮定にしたがったＡＰＩビット値が、ＡＰＩデコーダにより使用されてもよい。異なる仮定は異なるＡＰＩビット値を有するので、デコーディング性能は仮定ごとに変化するかもしれない。図１５〜１７は、異なるチャネルにわたる異なる仮定間での性能の変化を示す、例示的なグラフを示している。] 図１５ 図１６ 図１７
[0063] 図１５は、加法性ホワイトガウスノイズ（ＡＷＧＮ）チャネルにおける、異なる仮定Ｌ０〜Ｌ６に対するＡＰＩデコーディングのシミュレーション結果を示している。シミュレーションでは、すべての仮定が正しいと仮定する（いいかえると、ＡＰＩビット値が実際のエンコードされたビット値に合致すると仮定する）。] 図１５
[0064] 示しているように、より多くのＡＰＩビットを持つ仮定が、より良い性能（ビットエラーレートの減少）をもたらす。図１６は、ＩＴＵＰｅｄ−ＡおよびＰｅｄ−Ｂチャネルに対して異なる仮定を使用するＡＰＩデコーディングに対する、類似した結果を示している。図１７は、ＩＴＵ Ｖｅｈ−ＡおよびＶｅｈ−Ｂチャネルに対して異なる仮定を使用するＡＰＩデコーディングに対する、類似した結果を示している。] 図１６ 図１７
[0065] ここで使用したように、用語「決定する」は、幅広いさまざまな動作を含んでいる。例えば、「決定する」は、算出する、計算する、処理する、導出する、調べる、検索する（例えば、表、データベース、または、別のデータ構造中において検索する）、確認する、および、これらに類するものを含んでいてもよく、逆もまた同じである。同様に、「決定する」は、受け取る（例えば、情報を受け取る）、アクセスする（例えば、メモリ中のデータにアクセスする）、および、これらに類するものを含んでいてもよい。さらに、「決定する」は、解決する、選択する、選ぶ、確立する、および、これらに類するものを含んでいてもよく、逆もまた同じである。]
[0066] 情報および信号は、さまざまな異なるテクノロジーや技術のうちのいずれかを使用して、表現されてもよい。例えば、上記の記述全体を通して参照される、データ、命令、コマンド、情報、信号、および、これらに類するものは、電圧、電流、電磁波、磁界または磁粒、光場または光粒子、あるいは、これらを任意に組み合わせたものにより表現されてもよい。]
[0067] 本開示に関連して記述した、さまざまな例示的な論理的ブロック、モジュールおよび回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ信号（ＦＰＧＡ）または他のプログラマブルロジックデバイス、ディスクリートゲートまたはトランジスタロジック、ディスクリートハードウェアコンポーネント、あるいは、ここで記述した機能を実施するために設計されたこれらの任意の組み合わせで、実現されるか、あるいは、実施されてもよい。汎用プロセッサはマイクロプロセッサであってもよいが、代替的には、プロセッサは、何らかの市販のプロセッサ、制御装置、マイクロ制御装置、または、状態機械であってもよい。プロセッサはまた、コンピューティングデバイスの組み合わせとして、例えば、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアを備えた１つ以上のマイクロプロセッサ、あるいは、このような構成の他の何らかのものとして実現されてもよい。]
[0068] 本開示に関連して記述した方法またはアルゴリズムのステップは、直接、ハードウェアで、プロセッサにより実行されるソフトウェアモジュールで、あるいは、２つを組み合わせたもので具体化してもよい。ソフトウェアモジュールは、技術的に知られている何らかの形態の記憶媒体中に存在していてもよい。使用される記憶媒体のいくつかの例は、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーブバルディスク、ＣＤ−ＲＯＭ等を含んでいる。ソフトウェアモジュールは、単一の命令または多くの命令を含んでおり、複数の異なるコードセグメントを介して、異なるプログラム間で、および、複数の記憶媒体にわたって、配布されてもよい。記憶媒体は、プロセッサが記憶媒体から情報を読み取り、記憶媒体に情報を書き込むことができるようにプロセッサに結合されていてもよい。代替実施形態では、記憶媒体はプロセッサと一体化していてもよい。]
[0069] ここで記述した方法は、記述した方法を達成するための１つ以上のステップまたはアクションを含んでいてもよい。方法ステップおよび／またはアクションは、特許請求の範囲から逸脱することなく、相互に入れかえることができる。いいかえると、特定の順序のステップまたはアクションが明記されていないなら、特定のステップおよび／またはアクションの順序および／または使用は、特許請求の範囲から逸脱することなく、修正することができる。]
[0070] 記述した機能は、ハードウェア、ソフトウェア、ファームウェア、または、これらの何らかの組み合わせで実現されてもよい。ソフトウェアで実現された場合、コンピュータ読み取り可能媒体上の１つ以上の命令として、機能を記憶してもよい。記憶媒体は、コンピュータによりアクセスすることができる何らかの利用可能な媒体であってもよい。一例として、このようなコンピュータ読み取り可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、または他の光ディスク記憶デバイス、磁気ディスク記憶デバイス、または、他の磁気記憶デバイス、あるいは、命令またはデータ構造の形態で、所望のプログラムコードを実行するまたは記憶するために使用することができ、コンピュータによりアクセスできる他の何らかの媒体を含むことができるが、これらに限定されるものではない。ここで使用するようなディスク（ｄｉｓｋおよびｄｉｓｃ）は、コンパクトディスク（ＣＤ）、レーザディスク（登録商標）、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピー（登録商標）ディスク、ブルーレイ（登録商標）ディスクを含んでいる。ここで、ディスク（ｄｉｓｃ）がデータを光学的にレーザによって再生する一方で、ディスク（ｄｉｓｋ）は通常、磁気的にデータを再生する。]
[0071] さらに、ソフトウェアまたは命令は、送信媒体を介して送信されてもよい。例えば、同軸ケーブル、光ファイバケーブル、撚り対、デジタル加入者回線（ＤＳＬ）、または、赤外線、無線、および、マイクロ波のようなワイヤレス技術を使用しているウェブサイト、サーバ、あるいは、他のリモートソースから、ソフトウェアが送信される場合、同軸ケーブル、光ファイバケーブル、撚り対、ＤＳＬ、または、赤外線、無線、および、マイクロ波のようなワイヤレス技術は、送信媒体の定義に含まれる。]
[0072] さらに、ここで記述した方法および技術を実施するためのモジュールおよび／または他の適切な手段は、適用可能なものとして、移動体デバイスおよび／または基地局によりダウンロードできるか、および／または、そうでなければ、移動体デバイスおよび／または基地局により取得できることを理解すべきである。例えば、ここで記述した方法を実施するための手段の伝送を容易にするために、このようなデバイスをサーバに結合することができる。代替的には、記憶装置手段（ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、コンパクトディスク（ＣＤ）またはフロッピーディスクのような物理的な記憶媒体等）を介して、ここで記述したさまざまな方法を提供できる。それにより、記憶装置手段をデバイスに結合すると、または、記憶装置手段をデバイスに備えると、移動体デバイスおよび／または基地局は、さまざまな方法を取得できる。さらに、ここで記述した技術および方法をデバイスに提供するための他の何らかの適切な技術を利用できる。]
[0073] 特許請求の範囲は、上記で示したまさにその構成およびコンポーネントに限定されるものではないことが理解される。さまざまな修正、変更、および、バリエーションが、上記で記述した方法および装置の構成、運用、および、詳細において、特許請求の範囲から逸脱することなく行われてもよい。]
[0074] 前述は、本発明の実施形態に向けられたものであったが、本発明の他のおよびさらなる実施形態が、その基本的な範囲から逸脱することなく考案されてもよい。その範囲は、以下に続く特許請求の範囲により決定される。]
[0075] 前述は、本発明の実施形態に向けられたものであったが、本発明の他のおよびさらなる実施形態が、その基本的な範囲から逸脱することなく考案されてもよい。その範囲は、以下に続く特許請求の範囲により決定される。]

权利要求:

請求項1
ワイヤレス通信送信のエンコードされたデータビットをデコードするための方法において、前記エンコードされたデータビットの既知のビット値に対応する、１組のアプリオリビット値を発生させることと、前記１組のアプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスを、可能性あるデコーディングパスの集合から除去することと、除去されなかった可能性あるデコーディングパスのうちの残存デコーディングパスから、デコーディングパスを選択することにより、前記エンコードされたデータビットをデコードすることとを含む方法。
請求項2
前記１組のアプリオリビット値を発生させることは、ワイヤレス通信システムによりサポートされている限られた数のコード化スキームに基づいて、１組のビット値を発生させることを含む請求項１記載の方法。
請求項3
前記１組のアプリオリビット値を発生させることは、メッセージの長さに関する仮定に基づいて、メッセージの長さフィールドに対応する１組のビットを発生させることを含む請求項１記載の方法。
請求項4
デコーディングパスを除去するときに前記１組のアプリオリビット値からの少なくとも１つの値を考慮するか否かを示す、１組のマスクビットを発生させることをさらに含む請求項１記載の方法。
請求項5
前記１組のアプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスを除去することは、前記１組のアプリオリビット値と一致しないビット値に対応する、状態遷移に対する分岐メトリックを調整することを含む請求項１記載の方法。
請求項6
ワイヤレス通信送信のエンコードされたデータビットをデコードするデコーダにおいて、前記エンコードされたデータビットの分岐メトリックを計算する分岐メトリックユニットと、前記分岐メトリックに基づいて、デコードされたビットを発生させる際に使用するデコーディングパスを選択する加算比較選択ユニットと、前記デコーディングパスを選択するとき、前記エンコードされたデータビットの仮定値に対応する１組の１つ以上のアプリオリビット値と一致しない、デコードされたビット値に対応する１つ以上のデコーディングパスを、加算比較選択ユニットによる考慮から除去するロジックとを具備するデコーダ。
請求項7
前記除去するロジックは、前記１つ以上のアプリオリビット値と一致しないビット値に対応する分岐メトリックを変更するように構成されているロジックを備える請求項６記載のデコーダ。
請求項8
前記１つ以上のアプリオリビット値と一致しないビット値に対応する分岐メトリックを変更することは、前記変更する分岐メトリックにワーストケース値を割り当てることを含む請求項７記載のデコーダ。
請求項9
前記除去するロジックは、前記１つ以上のアプリオリビット値の表示と、前記デコードされたデータビット内の対応するビットロケーションの表示とを受け取る請求項６記載のデコーダ。
請求項10
前記除去するロジックは、前記１組のアプリオリビット値からの少なくとも１つの値を無視するか否かを示す、マスクビットを受け取る請求項６記載のデコーダ。
請求項11
前記デコーダは、ビタビデコーダである請求項６記載のデコーダ。
請求項12
前記デコーダは、組織コードでエンコードされたデータをデコードするように構成されている請求項６記載のデコーダ。
請求項13
ワイヤレス通信のための受信機において、ワイヤレス送信を受信して、１組のエンコードされたビットを発生させる受信機フロントエンドと、１組のアプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスを、可能性あるデコーディングパスの集合から除去することと、除去されなかった可能性あるデコーディングパスのうちの残存デコーディングパスから、デコーディングパスを選択することとにより、前記エンコードされたビットをデコードするように構成されているデコーダとを具備する受信機。
請求項14
メッセージプロセッサにより提供されたメッセージ情報に基づいて、前記１組のアプリオリビット値を発生させるロジックをさらに具備する請求項１３記載の受信機。
請求項15
前記１組のアプリオリビット値を発生させるロジックは、複数の組のアプリオリビット値を発生させるように構成されており、前記１組のアプリオリビット値は、複数の組のアプリオリビット値のうちの１つであり、前記複数の組のアプリオリビット値のうちの少なくとも２つが、指定された値を持つ異なる数のビットを有する請求項１４記載の受信機。
請求項16
前記ロジックは、以前に受信した送信からの少なくとも１つのビット値に基づいて、前記１組のアプリオリビット値からの少なくとも１つの値を指定するように構成されている請求項１３記載の受信機。
請求項17
前記以前に受信した送信は、ダウンリンクフレームプリフィックス（ＤＬＦＰ）メッセージを含む請求項１６記載の受信機。
請求項18
前記デコーダはビタビデコーダである請求項１３記載の受信機。
請求項19
ワイヤレス通信のための装置において、ワイヤレス送信を受信して、１組のエンコードされたビットを発生させる手段と、１組のアプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスを、可能性あるデコーディングパスの集合から除去することと、除去されなかった可能性あるデコーディングパスのうちの残存デコーディングパスから、デコーディングパスを選択することとにより、前記エンコードされたビットをデコードする手段とを具備する受信機。
請求項20
前記デコードする手段は、前記１つ以上のアプリオリビット値と一致しないビット値に対応する分岐メトリックを変更する手段を備える請求項１９記載の装置。
請求項21
コンピュータ読み取り可能媒体上に１組の命令を記憶させたコンピュータ読み取り可能媒体を具備する、ワイヤレス通信のためのコンピュータプログラムプロダクトにおいて、前記１組の命令は、１つ以上のプロセッサにより実行可能であり、前記１組の命令は、ワイヤレス送信を受信して、１組のエンコードされたビットを発生させるための命令と、１組のアプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスを、可能性あるデコーディングパスの集合から除去することと、除去されなかった可能性あるデコーディングパスのうちの残存デコーディングパスから、デコーディングパスを選択することとにより、前記エンコードされたビットをデコードするための命令とを含むコンピュータプログラムプロダクト。
請求項22
前記デコードするための命令は、１つ以上のアプリオリビット値と一致しないビット値に対応する分岐メトリックを変更するための命令を含む請求項２１記載のコンピュータプログラムプロダクト。
請求項23
コンピュータ読み取り可能媒体上に１組の命令を記憶させたコンピュータ読み取り可能媒体を具備する、ワイヤレス通信送信のエンコードされたデータビットをデコードするためのコンピュータプログラムプロダクトにおいて、前記１組の命令は、１つ以上のプロセッサにより実行可能であり、前記１組の命令は、前記エンコードされたデータビットの既知のビット値に対応する１組のアプリオリビット値を発生させるための命令と、前記１組のアプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスを、可能性あるデコーディングパスの集合から除去するための命令と、除去されなかった可能性あるデコーディングパスのうちの残存デコーディングパスから、デコーディングパスを選択することにより、前記エンコードされたデータビットをデコードするための命令を含むコンピュータプログラムプロダクト。
請求項24
前記１組のアプリオリビット値を発生させるための命令は、ワイヤレス通信システムによりサポートされている限られた数のコード化スキームに基づいて、１組のビット値を発生させるための命令を含む請求項２３記載のコンピュータプログラムプロダクト。
請求項25
前記１組のアプリオリビット値を発生させるための命令は、メッセージの長さに関する仮定に基づいて、メッセージの長さフィールドに対応する１組のビットを発生させるための命令を含む請求項２３記載のコンピュータプログラムプロダクト。
請求項26
デコーディングパスを除去するときに前記１組のアプリオリビット値からの少なくとも１つの値を考慮するか否かを示す、１組のマスクビットを発生させるための命令をさらに含む請求項２３記載のコンピュータプログラムプロダクト。
請求項27
前記１組のアプリオリビット値と一致しないデコードされたデータビットに対応するデコーディングパスを除去するための命令は、前記１組のアプリオリビット値と一致しないビット値に対応する、状態遷移に対する分岐メトリックを調整するための命令を含む請求項２３記載のコンピュータプログラムプロダクト。
請求項28
ワイヤレス通信送信のエンコードされたデータビットをデコードする装置において、前記エンコードされたデータビットの既知のビット値に対応する、１組のアプリオリビット値を発生させる手段と、前記１組のアプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスを、可能性あるデコーディングパスの集合から除去する手段と、除去されなかった可能性あるデコーディングパスのうちの残存デコーディングパスから、デコーディングパスを選択することにより、前記エンコードされたデータビットをデコードする手段とを具備する装置。
請求項29
前記１組のアプリオリビット値を発生させる手段は、ワイヤレス通信システムによりサポートされている限られた数のコード化スキームに基づいて、１組のビット値を発生させる手段を備える請求項２８記載の装置。
請求項30
前記１組のアプリオリビット値を発生させる手段は、メッセージの長さに関する仮定に基づいて、メッセージの長さフィールドに対応する１組のビットを発生させる手段を備える請求項２８記載の装置。
請求項31
デコーディングパスを除去するときに前記１組のアプリオリビット値からの少なくとも１つの値を考慮するか否かを示す、１組のマスクビットを発生させる手段をさらに具備する請求項２８記載の装置。
請求項32
前記１組のアプリオリビット値と一致しない、デコードされたデータビットに対応するデコーディングパスを除去する手段は、前記１組のアプリオリビット値と一致しないビット値に対応する、状態遷移に対する分岐メトリックを調整する手段を備える請求項２８記載の装置。